1. Field of the Invention
The present invention relates generally to computing systems, and more particularly to, systems and methods for path resolving in symmetric InfiniBand (IB) networks.
2. Description of the Related Art
Individual nodes in IB networks are typically addressed by a LID (local identifier) that is assigned by a Subnet Manager, which a software entity that is responsible for discovery of nodes, assignment of LID addresses, and configuration of a routing table of switches. Certain protocols (e.g., connection mode negotiation) require exchanging of path record information, which may include additional parameters like a source Global Identifier (GID), a destination GID, a data rate, a Maximum Transit Unit (MTU), a partition key (PKEY), a flow label, a service level, a traffic class, and the like parameters. While some of these parameters are rarely used, knowing source and destination GID addresses, MTU, and PKEY are typically required when path record information is exchanged.
Typically, a Subnet Manager (SM) entity is queried for path record information and the existing software API requires to perform the following procedure: 1 ) resolving the SM address (e.g., port_id_t type); 2) resolving the source GID using the source LID and the SM address; 3) resolving the destination GID using the destination LID and the SM address; and 4) resolving a path record using the source and destination GID addresses and the SM address. Thus, it is generally required to send at least four (4) data packets to resolve the path record. These multiple steps lead to high latency in connection establishment and services bring-up, especially if the Infiniband cluster is booting after activation or software upgrade. The latency increases even more because the API is not atomic (i.e., the SM location may change during a boot and the resolved SM location may become invalid during the course of sending the four packets discussed above, which causes additional timeouts and requires restarting the procedure).